-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #81674
Closed
Closed
Rollup of 8 pull requests #81674
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On big-endian the values need to be right-aligned within a 64-bit register, as if the value had been read with a 64-bit load instruction.
This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021. It suggests to add `"{}", ` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized `std::panic::panic_any()` function as an alternative. It renames the lint to `non_fmt_panic` to match the lint naming guidelines.
Scalars can represent integers up to u128, but the docs state otherwise.
Previously, it's not clear what exactly should be added in the suggested where clause, so this adds an example to demonstrate.
Editorconfig is a lightweight specification that helps maintaining consistent coding/formatting style accross editors, especially those editors that are not explicitly aware of Rust and rustfmt. https://editorconfig.org/
Upgrade Chalk ~~Blocked on rust-lang/chalk#670~~ ~~Now blocked on rust-lang/chalk#680 and release~~ In addition to the straight upgrade, I also tried to fix some tests by properly returning variables and max universes in the solution. Unfortunately, this actually triggers the same perf problem that rustc traits code runs into in `canonicalizer`. Not sure what the root cause of this problem is, or why it's supposed to be solved in chalk. r? `@nikomatsakis`
…Simulacrum Add .editorconfig This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.
Add AArch64 big-endian and ILP32 targets This PR adds 3 new AArch64 targets: - `aarch64_be-unknown-linux-gnu` - `aarch64-unknown-linux-gnu_ilp32` - `aarch64_be-unknown-linux-gnu_ilp32` It also fixes some ABI issues on big-endian ARM and AArch64.
Add better diagnostic for unbounded Abst. Const ~~In the case where a generic abst. const requires a trivial where bound: `where TypeWithConst<const_fn(N)>: ,`, instead of requiring a where bound, just check that only consts are being substituted in to skip over where check.~~ ~~This is pretty sketchy, but I think it works. Presumably, if there is checking for type bounds added later, it can first check nested requirements, and see if they're satisfied by the current `ParamEnv`.~~ Changed the diagnostic to add a better example, which is more practical than what was previously proposed. r? `@lcnr`
Directly use `Option<&[T]>` instead of converting from `Option<&Vec<T>>` later on `@rustbot` modify labels +C-cleanup +T-compiler
Add lint for `panic!(123)` which is not accepted in Rust 2021. This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021. It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized `std::panic::panic_any()` function as an alternative. It renames the lint to `non_fmt_panic` to match the lint naming guidelines. ![image](https://user-images.githubusercontent.com/783247/106520928-675ea680-64d5-11eb-81f7-d8fa48b93a0b.png) This is part of rust-lang#80162. r? `@estebank`
…ewording, r=estebank Improve wording of suggestion about accessing field Follow-up to rust-lang#81504 The compiler at this moment suggests "you might have meant to use field `b` of type `B`", sounding like it's type `B` which has the field `b`. r? `@estebank`
Fix out of date `Scalar` documentation Scalars can represent integers up to `u128`, but the docs state otherwise.
@bors r+ p=8 rollup=never |
📌 Commit ddf8dc7 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Feb 2, 2021
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors r- |
bors
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Feb 2, 2021
How did #81645 pass its checks if this fails here? 🤔 |
Ah. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Option<&[T]>
instead of converting fromOption<&Vec<T>>
later on #81636 (Directly useOption<&[T]>
instead of converting fromOption<&Vec<T>>
later on)panic!(123)
which is not accepted in Rust 2021. #81645 (Add lint forpanic!(123)
which is not accepted in Rust 2021.)Scalar
documentation #81665 (Fix out of dateScalar
documentation)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup